Conventionally, RTP (Real Time Protocol) is widely used as a protocol in real-time data transmission such as streaming (IETF standard RFC1889 Internet: http://www.ietf.org/rfc/rfc1889.txt?number=1889, IETF standard RFC1889 Internet: http://www.ietf.org/rfc/rfc1890.txt?number=1890).
The RTP has a protocol to transmit a payload serving as a data main body and a protocol (RTCP: RTP Control Protocol) to control transmission of the payload. As the protocol to transmit a payload itself, UDP (User Datagram Protocol)/IP (Internet Protocol) is used, which does not send a packet arrival confirmation response and neglects a nonarrival packet. On the other hand, the RTCP is implemented on TCP/IP to monitor negotiation of transmission media and QoS (Quality of Service) and control the start/end of a session.
The RTP assumes a translator which converts a given RTP packet format and a mixer which integrates a plurality of RTP packet formats into one format. Hence, a format shown in FIG. 8 is used as an RTP packet format. The SSRC (Synchronization Source) Identifier of the format shown in FIG. 8 is a synchronous transmission source identifier indicating the transmission source of an RTP packet. The CSRC (Contribution Source) Identifier is a contribution transmission source identifier indicating a list of transmission sources which have contributed to transmission of the RTP packet. If the packet is transmitted via a translator, a translator identifier is added to the CSRC identifier. If the packet is transmitted via a mixer, a preceding SSRC identifier is added to the CSRC identifier, and the identifier of the mixer changes to a new SSRC identifier.
The sequence number is a serial number assigned to the payload of the RTP packet. The sequence number is monotonously incremented by “1” every time an RTP packet is transmitted. The time stamp indicates the time of RTP packet transmission. This time is not the actual transmission time of the RTP packet but a time relative to the transmission time of another RTP packet. The time is given by 32 bits.
An RTP packet with this format is basically downloaded from the transmission source to the transmission destination by using the UDP (User Datagram Protocol). The receiving side determines the download situations (communication state and channel state) on the basis of, e.g., the above-described sequence number and time stamp by using the RTCP and reports the situations to the transmission source periodically. The transmitting side executes transmission control by, e.g., adjusting the quality of the payload on the basis of the channel state report.
The outline of transmission control by the RTCP/RTP will be described on the basis of FIG. 9. Referring to FIG. 9, the client (receiving side) transmits an [OPTIONS] command to the server (transmitting side), thereby exchanging device information with each other. The server notifies the client of information about a transmission content by a [DESCRIBE] command. The client determines the content transmission method on the basis of the received information and notifies the server of the transmission method by a [SETUP] command. The client transmits a [PLAY] command to the server, thereby requesting the server to transmit the content.
The series of communications are executed without loss of information by using the RTCP implemented on the TCP/IP. More specifically, since the TCP/IP is used, if a packet is lost on the transmission channel, the packet loss state is recognized by the TCP/IP so that the packet is resent.
Next, contents (RTP packets) are continuously transmitted from the server to the client by using the RTP. The RTP used for this transmission is implemented on the UDP/IP. For this reason, even when an RTP packet is lost, the RTP packets are continuously transmitted without resending the lost packet.
Finally, when a [TEARDOWN] command in the RTCP is transmitted from the client to the server, the server stops transmitting RTP packets. The client detects an RTP packet loss or the like on the basis of the RTCP. If an RTP packet loss or the like is detected, the client transmits a [RESEND] command of the RTCP to the server after the end of continuous RTP packet reception based on the UDP, thereby requesting resending of the lost RTP packet.
In such transmission using the RTCP or RTP, no control to ensure a channel band necessary for data transmission is executed. In RFC2205 (IETF standard RFC2205 Internet: http://www.ietf.org/rfc/rfc2205.txt?number=2205), a band control protocol RSVP (Resource Reservation Protocol) has been developed. In the RSVP, a resource, i.e., channel band is reserved for a series of streaming data.
FIG. 10 shows the arrangement of a host and a router used when a channel band is reserved by the RSVP. In the host shown in FIG. 10, an application claims the priority for an RSVP Process. If the claim of priority is authenticated by an Admission Control, and a Policy Control executes policy control, a packet classifier appends a classification parameter with high priority to a real-time stream generated from the application. A packet scheduler reserves a band preferentially for a packet of the real-time stream generated from the application.
This process is executed for a series of routers on the transmission path of host→router→ . . . →router→host, thereby ensuring the resource. As described above, in the RSVP, QoS is set for the host-to-host transmission path to ensure the band.
In the conventional transmission method, however, it may be impossible to reliably transmit streaming data (real-time data) such as image or audio data because of the influence of, e.g., a transmission delay, fluctuation, or packet loss that occurs in an intermediate device such as a switch or router in the network.